Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-x400ops-dnsx400rout-01.txt < prev next >

Wrap

Text File | 1993-03-03 | 45.7 KB | 1,180 lines

Network Working Group February 1993 Internet-DRAFT v4.1 Using the Internet DNS to maintain X.400 MHS Routing Informations Claudio Allocchio (Allocchio@elettra.trieste.it) Antonio Blasco Bonito (bonito@cnuce.cnr.it) Bruce Cole (bcole@cisco.com) Silvia Giordano (giordano@cscs.ch) Robert Hagens (hagens@ans.net) GARR-Italy Cisco Systems Inc. Centro Svizzero Calcolo Scientifico Advanced Network & Services 0. Status of this memo This memo proposes a method of storing in the Internet Domain Name System the routing information needed by X.400 MTAs within an X.400 MHS. Routing information can be managed in a distributed rather than a centralized way. MTAs located on Internet hosts can retrieve the routing information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This document specifies a prototype standard proposal. This memo is a joint effort of X400 operation working group and RARE Mail and Messaging working group. Distribution of this memo is unlimited. Another document by the same authors describes a method to store and distribute the RFC1327 mapping information using the Internet DNS. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Allocchio et. al. (Doc. expiration date: June 1993) [Page 1] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 1. Introduction The routing informations are an essential element to implement an efficient e-mail service within any community. In the Internet Domain Name System the "A" and "MX" records are used to store and distribute dynamically the routing information used by mailers to transport and deliver e-mail messages. In X.400 MHS usually static tables contain the routing data. In the early X.400 times, the MHS configurations were quite simple: a few well managed MTAs (often called "Well known Entry Point" or "WEP") were taking care of the whole routing for one or more communities; all the traffic was managed by static point-to-point connections among the WEPs, and often there was only one network transport available (usually X.25 or TCP with RFC1006). In this situation static tables proved to be enough to run such initial service. The rapid growth of X.400 Message Handling Systems, however, made very soon inadequate the use of a simple statically defined database: in fact the X.400 addresses tree grows daily adding new branches and many new MTAs show up either. More over a large number of X.400 implementations now support multiple transport stacks, allowing a real and global connectivity. Many efforts have been done in order to take in account this new situation, and a document defining the X.400 MHS routing strategy has been defined by Urs Eppenberger from SWITCH/COSINE MHS project team [EPPEN V3]. In that document the approach to the routing problem is again table driven, using the so called "DOMAIN" and "RELAY" tables (section 4). Two additional tables, "COMMUNITY" and "PERSON", complete the data about the X.400 MHS. That document, however, has been carefully designed to allow easily the store of the information it defines in distributed databases like DNS or X.500: our aim is to define the use of DNS to store those routing information. A first proposal to use the Internet DNS to store, to retrieve and to maintain X.400 related information (the RFC1327 mapping tables) was introduced by two of the authors (B. Cole and R. Hagens). However it required modifications to the actual Internet DNS nameservers and, due to the large variety of currently available implementations, this was unfeasible within a reasonable time. A different approach, using already defined, commonly available DNS resource-record types to store the information is proposed now. In addition, the use of a new domain name space is envisaged in order to fully implement a distributed X.400 routing information tree: again the MX resource-records will be used, jointly with some other ones needed to store the more complex X.400 routing data. The creation of the new domain name space also provides the chance to use the DNS to distribute dynamically the X.400 to/from RFC822 Allocchio et. al. (Doc. expiration date: June 1993) [Page 2] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 mapping information described in RFC1327, thus solving another efficiency problems currently affecting the X.400 MHS implementations. In this paper we will adopt the DOMAIN and RELAY document definitions from [EPPEN V3] routing coordination document. 1.1 Definitions syntax The definitions in this document is given in BNF-like syntax, using the following conventions: | means choice \ is used for continuation of a definition over several lines [] means optional {} means repeated one or more times The definitions, however, are detailed only until a certain level, and below it self-explaining character text strings will be used. 2. Motivation The implementation of a fully meshed connectivity among MTAs, and the ability to use at best the available network transport stacks require to disseminate complete and up to date routing data to all MTAs. In the Internet community, the DNS has proven to be a practical mean for providing a distributed name service. Advantages of using a DNS based system over a table based approach for mapping between O/R addresses and domain names are: - It avoids fetching and storing of entire routing tables by every MTA wishing to use full connectivity. - Modifications to the DNS based routing information can be made available in a more timely manner than with a table driven approach. - Table management is not necessarily required for DNS-based X.400 MTAs. - One can determine the routing in use by a remote MTA by querying the DNS (remote debugging). Routing decisions taken by the MTAs involved in delivering an X.400 message will also be more likely to result correct, if the routing information is updated in real time. 3. Proposal: the new "X400.ARPA" domain space Usual domain names (the ones normally used as the global part of an RFC822 e-mail address) and their associated information, i.e. host IP addresses, mail exchanger names, etc., are stored in the DNS as a Allocchio et. al. (Doc. expiration date: June 1993) [Page 3] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 distributed database under a number of top-level domains (EDU, COM, countries like UK, IT, FR, etc.). The special top-level/second-level couple IN-ADDR.ARPA is used to store the IP address to domain name relationship. Our proposal, which closely resembles the above model, is to store the X.400 routing data in a new branch of the DNS name space (under the already defined top-level domain "ARPA") using the MX and HINFO resource records. In particular in this new name space "X400.ARPA" we will have a complete set of existing resource records available to store any other useful information concerning X.400, like RFC1327 mappings, responsible people, etc. This name space is thus used to contain completely the information: the data required by an MTA to route an X.400 message to destination can be easily found with a simple query to the nearest nameserver. Moreover there is no more any need to store, maintain and distribute manually those tables. The special name space begins at the top-level "X400.ARPA" and should have a structure following the X.400 hierachical structure (country, ADMD, PRMD, organisation, ...). The fully qualified MX and HINFO resource-records are constructed starting from the information contained in the DOMAIN and RELAY documents. The construction of the new domain space tree will follow the same procedures used when organising at first the already existing DNS space: authoritative information about the X400.ARPA top-level domain is maintained by the root servers while a central nameserver in each country is delegated by the root servers to hold the national part of the routing tables. At first, however, the information will be stored in a quite centralised way, and distribution of authority will be gradually achieved. A separate document will describe the implementation phase. 4. Storing X.400 routing information In the usual domain name space the MX records are used to store information for SMTP mailers; their content is a list of possible Mail eXchanger and a pure number stating the preferred order of these mailers (priority). The creation of a new domain space under X400.ARPA top level domain, enables now us to use the MX resource records in it to store information about routing in the X.400 MHS, using the same principles adopted by SMTP mailers. Some other DNS resource records will then be used to store the additional data present in the RELAY and DOMAIN documents described in sect. 5.3 and 5.4 of [EPPEN V3] document. The syntax form of the usual MX record in DNS is: <domain> <class> MX <prio> <dest-host-domain> Allocchio et. al. (Doc. expiration date: June 1993) [Page 4] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 where <dest-host-domain> is then resolved via an "A" resource record into an IP host address: in fact the only transport foreseen in DNS for SMTP protocol is TCP/IP, and the socket number 25 is already reserved. Also NJE, DDCMP and X.25 transports are used for SMTP (BSMTP, DSMTP and XSMTP), but their connection data are not included and distributed via DNS. In the X.400 MHS routing document we can identify these elements: <OR-matching><MHS-subtree> <RELAY-Priority> <UniqueRELAYkey> which can be somehow equivalenced to the usual DNS elements. However the routing can be done on different protocol stacks, and each stack can have a different priority. Thus we have additional data for each specific stack like <Service-type>, <P-address>, <Service-priority>, <MTS>. On the other hand, the MTA connection data are much more complex than a simple 4-byte IP address. We have in fact <RTS>, <password>, <called-connection>, <calling connection>, etc. and many of these elements are themselves a set of complex data. Thus we will need additional resource records to store these data. 4.1 Detailed storage proposal for routing information in DNS To implement in the most convenient way the storage of X.400 MHS routing data we can take advantage of the DNS MX records; in fact they already provide wildcard support and a priority mechanism. Other available DNS resource record types will be then used for the remaining RELAY data; in particular the HINFO resource record can be used for the RELAY connection and system data. Let us define the <MHS-route-record> object which can be inserted into a DNS MX resource record: <MHS-route-record> ::= <MHS-ORdomain> "IN" "MX" <RELAY-priority> \ <RELAY-data> where: <MHS-ORdomain> ::= DNS translation of <OR-matching><MHS-subtree> (sect. 4.3.1) <RELAY-priority> ::= <Number 0..99> (see [EPPEN V3] sect. 5.4) <RELAY-data> ::= { <DNS-Service-key> ["-" <DNS-Priority>] "." } \ <DNS-RELAYkey> <DNS-Service-key> ::= A unique keyword to identify a <RELAY-call-data> and <RELAY-clng-data> record (sect. 4.3.5) Allocchio et. al. (Doc. expiration date: June 1993) [Page 5] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 <DNS-Priority> ::= DNS translation of <Service-priority> (sect. 4.3.4) <DNS-RELAYkey> ::= DNS translation of <UniqueRELAYkey><local-domain> (sect. 4.3.2) The presence of <OR-matching> element in the DOMAIN document determines the distinction between wildcard and exact matching of an O/R address with <MHS-subtree>: in DNS this will be implemented with the provided MX wildcard mechanism (see an example in section 4.3.1). The <DNS-RELAYkey>, as you can see, is the translation of the combination of <UniqueREALYkey> and <local-domain>; this requires the mandatory presence of the <local-domain> information, even if this information is defined as optional in [EPPEN V3]. The <DNS-RELAYkey> must in fact be located in the correct branch of the X400.ARPA DNS tree, i.e. exactly where the authority managing the RELAY lies. A similar situation occurs also for the location of the MTA object within the X.500 tree. As a consequence, for a community wishing to distribute its routing information via DNS, the <local-domain> element becomes mandatory. The additional data for a RELAY connection are stored into HINFO DNS resource records. In particular we need to store information about the RELAY itself (<status>, <password>, <RTS>, <system>) and about the network connectivity (<service-type>, <MTS> and <P-address>). We define thus three records, which will be stored into three different DNS HINFO records: <RELAY-host-data> ::= <DNS-RELAYkey> "IN" "HINFO" \ "<status> <password> <DNS-RTS> [<system>]" \ "<DNS-Service-key> { [ "." <DNS-Service-key> ] }" <RELAY-call-data> ::= "C."<DNS-Service-key>"."<DNS-RELAYkey> \ "IN" "HINFO" "<password> <DNS-RTS> <MTS>" \ "<P-address>" <RELAY-clng-data> ::= "R."<DNS-Service-key>"."<DNS-RELAYkey> "IN" \ "HINFO" "<password> <DNS-RTS>" "<P-address>" where: <DNS-RTS> ::= DNS translation of <RTS> (sect. 4.3.3) and <status>, <password>, <system>, <MTS>, <P-address> are defined in [EPPEN V3], sect. 5.1 and 5.3. Note that the <DNS-Service-key> list contained into the <RELAY-host-data> record must contain exactly the same elements used for any couple of <RELAY-call-data> and <RELAY-clng-data> records, i.e. is we have 3 couples of connection information records using "XX0", "RX0" and "IT6" keys, then this list must be present in the <RELAY-host-data> record. Allocchio et. al. (Doc. expiration date: June 1993) [Page 6] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 The HINFO resource record can hold up to twice 256 octet strings, allowing thus enough available space even for complex <P-address> data. We can understand better the reason of the three HINFO resource records defined previously if we think of the multiple stacks available for an X.400 MHS: an MTA has some data which are independent from the network stack being used (stored into <RELAY-host-data>) and on the contrary some other information depending upon it (stored into <RELAY-call-data> and <RELAY-clng-data>). 4.2 Basic mappings The formal definition of an MX resource record is (RFC1035, sect. 3.3.9): +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EXCHANGE / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same "owner name". EXCHANGE A <domain-name> which specifies a host willing to act as a mail exchange for the "owner name". and also the "owner name" is a <domain-name> element. At the same time the formal definition of an HINFO resource record is (RFC1035, sect. 3.3.2) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CPU / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / OS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CPU and OS area both of <character-string> type and the "owner name" is a <domain-name> element. In our proposal, <MHS-ORdomain>, <RELAY-data>, <RELAY-host-data>, <RELAY-call-data> and <RELAY-clng-data> must thus be conformant with Allocchio et. al. (Doc. expiration date: June 1993) [Page 7] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 the <domain-name> syntax rules, i.e. <domain-name> ::= <subdomain> | " " <subdomain> ::= <label> | <label>.<subdomain> <label> ::= <alphanum> {<alphanumhyphen>} <alphanum> <alphanum> ::= "0".."9" | "A".."Z" | "a".."z" <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-" The definition of <character-string> is simpler: a contiguous set of characters without interior spaces, or a 'quoted string', i.e. beginning and ending with " (double quotes). Inside a quoted string any character can occur, except for a " itself, which must be quoted using \ (backslash). As you will notice, the legal character set for <label> does not correspond to the IA5 Printablestring one which is used in <MHS-subtree>; even worse for <uniqueRELAYkey> which can use any ASCII character from (032) up to (126) decimal. However a very simple "escape mechanism" can be applied in order to bypass the problem. 4.3 IA5 Printablestring and ASCII to <alphanumhyphen> mappings The problem of unmatching character set definition is solved by a simple character mapping rule: whenever a character does not belong to <alphanumhyphen>, then it is mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A small set of special rules is also defined for the most frequent cases. Moreover some frequent characters combinations are also mapped as special cases. In <MHS-subtree> and <uniqueREALYkey> we can identify a common structure: a sequence of <addr-element> <addr-element> ::= <attr-label> "=" <attr-value> <attr-label> ::= "C" | "A" | "P" | "O" | \ "OU1" | "OU2" | "OU3" | "OU4" | \ "MTAname" <attr-value> ::= IA5-Printablestring | ASCII(032)..ASCII(127) The label values differ from those defined in RFC1327 for the mapping rules. However both the mapping and routing rules share the same X400.ARPA name space, and thus the sub-trees must have consistent and coherent definitions. For this reason in the following table we also define the appropriate equivalencies. Allocchio et. al. (Doc. expiration date: June 1993) [Page 8] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 Let's then define the following simple rules: Original syntax DNS translation conditions -------------------------------------------------------------------- missing <attr-label> <attr-label> missing seq. element <attr-label>"="<blank> <attr-label>"b" blank attribute "C=" "C-" country code "A=" "ADMD-" administration domain "P=" "PRMD-" private domain "O=" "O-" organization "OU1=" "OU2=" "OU3=" "OU4=" "OU-" organization unit "MTAname=" "MTA-" MTA name Non <alphanumhyphen> characters in <attr-value>: Original character DNS translation conditions -------------------------------------------------------------------- - -h- hyphen . -d- quoted dot <blank> -b- blank non A/N character -<3digit-decimal>- elsewhere If the DNS store translation of <attr-value> happens to end with an hyphen, then this last hyphen is omitted. Let's now have some examples: Original syntax DNS store translation condition ------------------------------------------------------------------ missing PRMD PRMD missing attribute A=<blank> ADMDb blank attribute A=400-net ADMD-400-h-net hyphen mapping P=UB.AC PRMD-UB-d-AC quoted dot mapping O=ACME Inc. O-ACME-b-Inc-d blank & final hyphen P=main-400-a PRMD-main-h-400-h-a hyphen mapping O=-123-b O--h-123-h-b hyphen mapping OU1=123-x OU-123-h-x hyphen mapping More complete examples are shown in sect 4.3.1 and 4.3.2 In order to achieve the proper DNS store translations of the X.400 routing data some software tools will be used. It is in fact evident that the above conversion rules are not user friendly enough to think of a human made conversion. In the next paragraphs we will show for each translation a "step by step" procedure which can be interpreted as a small flow chart to help in designing the tools. The fundamental rule to be applied during translation is, however, the following: "A string must be parsed from left to right, moving appropriately the pointer in order not to consider again the already translated left section of the string in subsequent analysis." Allocchio et. al. (Doc. expiration date: June 1993) [Page 9] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 4.3.1 DNS translation of <OR-matching><MHS-subtree> The syntax for <MHS-ORdomain> corresponds in DNS to a <domain-name> element, while the <OR-matching> can fit into the wildcard specification preceding the <domain-name>. Thus we will follow the approach described in the previous section for non <alphanumhypehn> elements, and a similar solution for the general translation. The definition of <MHS-subtree> in [EPPEN V3] sect. 5.1 is: <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \ [[[["OU1="'OrganizationalUnit-name'"; "]\ "OU2=" 'OrganizationalUnit-name' "; "] \ "OU3=" 'OrganizationalUnit-name' "; "] \ "OU4=" 'OrganizationalUnit-name' "; "] \ ["P=" 'PRMDname' "; "] \ "A=" 'ADMDname' "; " \ "C=" 'Two Character Country Code ISO-3166' ";" i.e. a string made up by Attribute Labels ("C", "A", "P", "O", "OU1", "OU2", "OU3", "OU4") plus Attribute-Values and ";" as separators. This definition allows in its syntax to skip eventually missing intermediate address elements, instead of substituting them with a standard placeholder ("@") as defined in RFC1327 for mapping rules syntax. The new DNS tree under top level domain "X400.ARPA", however, must be coherent in order to allow a correct distribution of authority and a correct sequence of queries along its branches. Thus we will insert again the skipped attributes into our DNS translation of <MHS-subtree> and <UniqueRELAYkey>. An equivalent definition of <MHS-subtree> is: <MHS-subtree> ::= <addr-element> [ { ";" <addr-element> } ] <addr-element> ::= <attr-label> "=" <attr-value> <attr-label> ::= "C" | "A" | "P" | "O" | \ "OU1" | "OU2" | "OU3" | "OU4" <attr-value> ::= IA5-Printablestring To obtain our <DNS-ORdomain> we will use the above translation tables and use the rules described hereunder, along with a detailed example. Let us suppose: <MHS-subtree> = OU1=NYC; OU2=saled dpt.; P=AC-me; A= ; C=it; <OR-matching> = "* " 1) insert the missing attribute elements in <MHS-subtree> and reorder them as OU4, OU3, OU2, OU1, O, P, A, C: OU2=saled dpt.; OU1=NYC; O; P=AC-me; A= ; C=it; Allocchio et. al. (Doc. expiration date: June 1993) [Page 10] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 2) translate <attr-label> as defined above: OU=saled dpt.; OU=NYC; O; PRMD=AC-me; ADMD= ; C=it; 3) translate <attr-value> as defined above and convert = into -: OU-saled-b-dpt-d; OU-NYC; O; PRMD-AC-h-me; ADMDb; C-it; 4) replace ";" separators and eventual remaining blanks into ".": OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it. 5) add the top level domain "X400.ARPA" at the end: OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.X400.ARPA. 6) if <OR-matching> is "* ", then add "*." in front of the string: *.OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.X400.ARPA. The final result is then used in DNS as selector to find the appropriate X.400 routing RELAY on a best match basis, exactly as for the RFC822 domains. Let's have some other examples: <MHS-subtree> = P=WHY;A=mycom;C=ch; <OR-matching> = "* " is translated in <DNS-ORdomain> as *.PRMD-WHY.ADMD-mycom.C-ch.X400.ARPA. Another one: <MHS-subtree> = OU1=ACME Inc.;P=UB.AC;A= ;C=GB; <OR-matching> = "= " is translated in <DNS-ORdomain> as OU-ACME-b-Inc-d.O.PRMD-UB-d-AC.ADMDb.C-GB.X400.ARPA. 4.3.2 DNS translation of <UniqueRELAYkey><local-domain> The character set and syntax allowed for a <DNS-RELAYkey> is again the one corresponding in DNS to a <domain-name> element. Thus we will approach the problem as we did for <MHS-subtree>. Before looking into the translation algorhytm, we must point out again that the <DNS-RELAYkey> need to be placed into the correct branch of the X400.ARPA tree. <UniqueRELAYkey> contains already some keys which could help us in this definition; however they are not Allocchio et. al. (Doc. expiration date: June 1993) [Page 11] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 detailed enough to assure the correct result. Thus we need to make compulsory the presence of <local-domain> which locates fully and unambiguously the RELAY in the DNS tree. The <UniqueRELAYkey> and <local-domain> elements are defined in sect. 5.1 and 5.3 of [EPPEN V3]: <UniqueRELAYkey> ::= (["P=" 'PRMDname' "; "] ["A=" 'ADMDname' "; "] \ "C=" 'Two Character Country Code ISO-3166' "; " \ "MTAname=" 'MTAname' | <DirectoryName> ) <local-domain> ::= "LocalDomain: " <MHS-subtree> The <MHS-subtree> is local to the RELAY. Note that <UniqueRELAYkey> can also be a <DirectoryName>; however we need to specify completely the information in DNS, avoiding queries to other directory services like X.500. We will thus use the actual data in place of the <DirectoryName> distinguished object to define our <DNS-RELAYkey>. To define <DNS-RELAYkey> we will take "MTAname=" 'MTAname' from <UniqueRELAYkey> joining it with <MHS-subtree> from <local-domain>: "MTAname=" 'MTAname' "; " <MHS-subtree> Let us see in details the steps to obtain <DNS-RELAYkey>. We suppose: <UniqueRELAYkey> = P=ninf; A=rdnet; C=it; MTAname=int-gw.ninf.it <MHS-subtree> = OU1=int-gw; P=ninf; A=rdnet; C=it; 1) add MTAname in front of <MHS-subtree>: MTAname=int-gw.ninf.it; OU1=int-gw; P=ninf; A=rdnet; C=it; 2) insert the missing attribute elements in <MHS-subtree>: MTAname=int-gw.ninf.it; OU1=int-gw; O; P=ninf; A=rdnet; C=it; 3) translate <attr-label> as defined above: MTA=int-gw.ninf.it; OU=int-gw; O; PRMD=ninf; ADMD=rdnet; C=it; 4) translate <attr-value> as defined above and convert = into -: MTA-int-h-gw-d-ninf-d-it; OU-cosine-h-gw; O; PRMD-ninf; \ ADMD-rdnet; C-it; 5) replace ";" separators and eventual remaining blanks into ".": MTA-int-h-gw-d-ninf-d-it.OU-cosine-h-gw.O.PRMD-ninf.ADMD-rdnet.\ C-it. Allocchio et. al. (Doc. expiration date: June 1993) [Page 12] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 6) add the top level domain "X400.ARPA" at the end: MTA-int-h-gw-d-ninf-d-it.OU-cosine-h-gw.O.PRMD-ninf.\ ADMD-rdnet.C-it.X400.ARPA. This element is then ready to be used into DNS resource records. Let us have another example: <UniqueRELAYkey> = P=UB.AC; A= ; C=GB; MTAname=UB.AC.mhs-relay <MHS-subtree> = P=UB.AC; A= ; C=GB; is translated in <DNS-RELAYkey> as MTA-ub-d-ac-d-mhs-h-relay.PRMD-UB-d-AC.ADMDb.C-GB.X400.ARPA. 4.3.3 DNS translation of <RTS> The definition of <RTS> in [EPPEN V3], sect. 5.3 is <RTS> ::= <dialogue-mode> [<checkpoint-size> <window-size>] <dialogue-mode> ::= "RTS-dialog-mode: " ("TWA" | "MONOLOGUE") <checkpoint-size> ::= "RTS-checkpoint-size: " 'checkpoint size' <window-size> ::= "RTS-window-size: " 'window size' These data will be stored in DNS into HINFO resource records, and thus there is no limitation to the format or character set to use. However the information stored in DNS are for machine use; therefore we will define <DNS-RTS> as a short encoding of these data. In particular: <DNS-RTS> ::= <k-dialogue> [ <k-checkpoint> <k-window> ] with: <k-dialogue> ::= "T" | "M" <k-checkpoint> ::= "C" 'checkpoint size' <k-window> ::= "W" 'window size' Some examples: A connection with dialogue=TWA, checkpoint=19 and window=10 will result into TC19W10; A connection with dialogue=MONOLOGUE, checkpoint=5 and window=20 will result into MC5W20. 4.3.4 DNS translation of <Service-priority> As <Service-priority> is a pure number, we need to apply a label to it in order to be conformant with RFC1034 and also to distinguish it Allocchio et. al. (Doc. expiration date: June 1993) [Page 13] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 from the other elements. Thus our definition of <DNS-priority> is <DNS-priority> ::= "P" <Service-priority> If <Service-priority> is defined as "5", then its DNS translation will be "P5". 4.3.5 Defining the <DNS-Service-key> The <DNS-Service-key> is just a label to identify a DNS resource record where the relevant MTA connection data are stored. Thus its only requirement is to be unique within an MTA identified by <DNS-RELAYkey>. However it could be very useful to define some criteria and common abbreviations in order to have short keys and also some "guessable" keys for the most common cases. Our suggestion is to adopt a three characters key: <DNS-Service-key> ::= <k-name> <k-service> <k-protocol> <k-name> ::= one A/N character identifying the network name, adopting the following abbreviations: 'X' Public-X.25 'I' Internet 'R' EMPB-X25 'L' Int-CLNS <k-service> ::= "X" | "O" | "L" | "T" standing respectively for X.25, CONS, CLNS, TCP <k-protocol> ::= "0" | "2" | "4" | "6" standing respectively for TP0, TP2, TP4, RFC1006 Thus "Internet/TCP/RFC1006" will produce a <DNS-Service-key> = IT6, while "EMPB-X25/CONS/TP0" produces <DNS-Service-key> = RO0. 4.4 An example of DNS stored DOMAIN and RELAY documents As said in the previous sections, the X.400 MHS routing data can be stored in DNS using MX and HINFO reseouce records and the set of defined mapping rules. Let's see an example containing the routing data of a management domain. In particular we will consider a DOMAIN document with 2 RELAYs. Allocchio et. al. (Doc. expiration date: June 1993) [Page 14] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 DOMAIN document (part): Community: MY-MHS # Domain: * P=INT-Co; A=RDnet; C=CH; Domain: = P=WHY; A=RDnet; C=CH; Domain: * P=Net Lab; A=Pub400; C=CH; # RELAY: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one; 10 RELAY: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch; 60 RELAY document 1 (part): Community: MY-MHS # RELAY: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one # Status: primary Password: none RTS-dialog-mode: TWA RTS-checkpoint-size: 10 RTS-window-size: 19 # Called-address: Public-X.25/X.25/TP0; Int-X25(80)=22225971014110; MTS-TP-84; 30 Calling-address: Public-X.25/X.25/TP0; Int-X25(80)=22225971014 # Called-address: Internet/TCP/RFC1006; Internet-RFC-1006=140.105.1.1; MTS-TP-84; 10 Calling-address: Internet/TCP/RFC1006; Internet-RFC-1006=140.105.1.1 # System: HW=DEC VAX3100; OS=VMS 5.5; SW=EAN V2.2+ LocalDomain: O=LocDpt; P=INT-Co; A=RDnet; C=CH; # RELAY document 2 (part): Community: MY-MHS # RELAY: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch # Status: secondary Password: value="call-me" RTS-dialog-mode: MONOLOGUE # Called-address: EMPB-X25/X.25/TP0; Int-X25(80)=20432240004110; MTS-TP-84 Calling-address: EMPB-X25/X.25/TP0; Int-X25(80)=20432240004 # Allocchio et. al. (Doc. expiration date: June 1993) [Page 15] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 Called-address: Int-CLNS/CLNS/TP4; "88"/NS+39756f11112222223333aa00040005e100; MTS-TP Calling-address: Int-CLNS/CLNS/TP4; "88"/NS+39756f11112222223333aa00040005e100 # System: HW=Sun 3; OS=SunOS 5-2; SW=PP 6.0 LocalDomain: O=managment; P=Nat Sa; A=RDnet; C=CH; # The routing information contained in the above DOMAIN document will result into 3 couples of MX record, 2 couples with a wildcard specification and one couple with exact matching only. ; ; Domain: * P=INT-Co; A=RDnet; C=CH; --------------------------- ; *.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN MX 10 \ XX0-P30.IT6-P10.\ MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. ; *.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN MX 60 \ RX0.LL4.\ MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA. ; ; Domain: = P=WHY; A=RDnet; C=CH; ------------------------------ ; P-WHY.A-RDnet.C-CH.X400.ARPA. IN MX 10 \ XX0-P30.IT6-P10.\ MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. ; P-WHY.A-RDnet.C-CH.X400.ARPA. IN MX 60 \ RX0.LL4.\ MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA. ; ; Domain: * P=Net Lab; A=Pub400; C=CH; -------------------------- ; *.P-Net-b-Lab.A-Pub400.C-CH.X400.ARPA. IN MX 10 \ XX0-P30.IT6-P10.\ MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. ; *.P-Net-b-Lab.A-Pub400.C-CH.X400.ARPA. IN MX 60 \ RX0.LL4.\ MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA. ; The above records just specify the available relays and connection stacks, but does not yet contain the needed data to establish MTA to MTA links. These data are stored into the below HINFO resource records. Allocchio et. al. (Doc. expiration date: June 1993) [Page 16] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 ; ; RELAY: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one ---------------- ; MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN HINFO \ "primary none TC10W19 HW=DEC VAX3100; OS=VMS 5.5; SW=EAN V2.2+" \ "XX0.IT6" ; C.XX0.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \ IN HINFO "none TC10W19 MTS-TP-84" "Int-X25(80)=22225971014110" R.XX0.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \ IN HINFO "none TC10W19" "Int-X25(80)=22225971014" ; C.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \ IN HINFO "none TC10W19 MTS-TP-84" "Internet-RFC-1006=140.105.1.1" R.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \ IN HINFO "none TC10W19" "Internet-RFC-1006=140.105.1.1" ; ; RELAY: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch ------------ ; MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.\ IN HINFO \ "secondary value=\"call-me\" M HW=Sun 3; OS=SunOS 5-2; SW=PP 6.0" \ "RX0.LL4" ; C.RX0.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\ X400.ARPA. IN HINFO "value=\"call-me\" M MTS-TP-84" \ "Int-X25(80)=20432240004110" R.RX0.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\ X400.ARPA. IN HINFO "value=\"call-me\" M" "Int-X25(80)=20432240004" ; C.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\ X400.ARPA. IN HINFO "value=\"call-me\" M MTS-TP" "\"88\"/NS+39756f11112222223333aa00040005e100" R.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\ X400.ARPA. IN HINFO "value=\"call-me\" M" "\"88\"/NS+39756f11112222223333aa00040005e100" Note that the above lines have been wrapped for clarity reasons, using "\" to show continuation on the same line. Only inside the HINFO value the "\" is used to quote the " character and is actual part of the syntax. 4.5 An example of query to DNS for routing data In this example we will assume that the routing data those defined in section 4.4; let's see how it works. OR address: C=ch;A=RDnet;P=Int-Co;O=mgt;S=helpdesk; After translation of the routing part of the OR address in DNS Allocchio et. al. (Doc. expiration date: June 1993) [Page 17] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 syntax, a first query for an MX records list will be issued for O-mgt.PRMD-Int-h-Co.ADMD-RDnet.C-ch.X400.ARPA. DNS will match the query with the first couple of MX records listed in our above example, i.e. IN MX 10 XX0-P30.IT6-P10.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.\ C-CH.X400.ARPA. IN MX 60 RX0.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.\ A-RDnet.C-CH.X400.ARPA. The answer contains already a choice between 2 possible RELAYs and again 2 available connection stacks per each RELAY, identified by XX0, IT6, RX0 and LL4 keywords and with different priorities. Note that the <DNS-service-key> contained in each MX record is meaningful and must be unique only within a <DNS-RELAYkey>. As priority 10 indicated the preferred RELAY, and we already have also the preferred connection stack (identified by IT6 key, service priority 10) we can query directly for connection data, looking for an HINFO record like: C.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. and attempt connection to the remote RELAY. If this fails, according to [EPPEN V3] document, we will then query for the next supported stack connection record (identified by XX0 key with priority 30 and by the same <DNS-RELAYkey>). If also this connection fails we will eventually use the other available RELAY, and continue like that. On the other hand we can also query information about a specific RELAY starting from the <DNS-RELAYkey>: MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. It is thus possible to reconstruct the RELAY table data starting from DNS. 5. Administration of routing information Not all MTAs will be able to use the Internet DNS to obtain the X.400 routing information. It is in fact expected that MTAs in a particular country or management domain will conform to one of the following models: Table-based DNS-based X.500-based Table-based countries and management domains will submit and receive their routing documents from the International MHS coordinator. DNS Allocchio et. al. (Doc. expiration date: June 1993) [Page 18] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 based countries and management domains will store their routing information in the DNS. The DNS Routing coordinator will be responsible for operating authoritative nameservers for resource records pertinent to management domains in Table-based communities. Also, the DNS Routing coordinator will be responsible for generating the table form of routing data based in the DNS and transmitting it to the International Routing Table coordinator. X.500 based storage is not yet fully defined. As of this writing, the International Routing Table coordinator is the COSINE MHS Project Team and the DNS Routing coordinator is the COSINE Gateway Service. A set of coordination procedures to keep aligned the three routing distribution services will be published in the implementation phase document. 6. Conclusion The use of the MX and HINFO resource-records and a new name space tree promise to provide a good possible repository for X.400 MHS routing information. The information is stored in the DNS tree structure so that it can be easily obtained using the DNS distributed name-service. At the same time the introduction of the new "X400.ARPA" domain name space allows us also to use the DNS to store and distribute many other X.400 MHS information, including the mapping ones. The use of the DNS has many advantages in storing, managing and updating information. Using the existing resource records in the new name tree does not even require the introduction of new types. A successful number of tests have been performed under the provisional top level domain "X400.IT", and their results confirmed the advantages of the method. Software to query the DNS and then to convert between the textual representation of DNS resource records and the address format defined in [EPPEN V3] needs to be developed. Also some tools to derive DNS format from DOMAIN and RELAY documents will be needed to help the implementation of this specification. 7. References [CCITT] CCITT SG 5/VII, "Recommendation X.400," Message Handling Systems: System Model - Service Elements, October 1988. [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC 822", RFC 1327, March 1992 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, February 1987. Allocchio et. al. (Doc. expiration date: June 1993) [Page 19] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 [RFC 1035] Mockapetris, P., "Domain names - Implementation and Specification", RFC 1035, USC/Information Sciences Institute, November 1987. [EPPEN V3] Eppenberger, U., "Routing coordination for X.400 MHS services within a multi protocol / multi network environment - Table Format V3 for static routing", Internet-Draft, COSINE-MHS/SWITCH, February 1993. 8. Authors addresses: Claudio Allocchio RFC822: Claudio.Allocchio@elettra.trieste.it Sincrotrone Trieste X.400: C=it;A=garr;P=infn;OU=elettra-ts; c/o Area di Ricerca S=Allocchio;G=Claudio; Padriciano 99 Phone: +39 40 3758523 I 34012 Trieste Fax: +39 40 226338 Italy Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it CNUCE - CNR X.400: C=it;A=garr;P=cnr;O=cnuce;S=bonito; Reparto infr. reti Phone: +39 50 593246 Viale S. Maria 36 Fax: +39 50 589354 I 56126 Pisa Italy Bruce Cole RFC822: bcole@cisco.com Cisco Systems Inc. X.400: C=us;A= ;P=Internet; P.O. Box 3075 DD.rfc-822=bcole(a)cisco.com; 1525 O'Brien Drive Phone: +1 415 6888245 Menlo Park, CA 94026 Fax: +1 415 6884575 U.S.A. Silvia Giordano RFC822: giordano@cscs.ch Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs; Calcolo Scientifico S=giordano; Via Cantonale Phone: +41 91 508213 CH 6928 Manno Fax: +41 91 506711 Switzerland Robert Hagens RFC822: hagens@ans.net Advanced Network X.400: C=us;A= ;P=Internet; and Services DD.rfc-822=hagens(a)ans.net; 1875 Campus Commons Phone: +1 703 7587700 Drive Reston, VA 22091 U.S.A. Allocchio et. al. (Doc. expiration date: June 1993) [Page 20]